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SPECIFICATION 



TITLE OF INVENTION 
METHOD AND SYSTEM FOR PROVIDING NETWORK ACCESS TO PPP 



Field of the Invention 

The present invention relates to the field of network communications. More 
10 specifically, the present invention relates to a method and apparatus for providing 
computer network access to PPP clients. 



The Background Art 



Computer networking capabilities of a home personal computer (PC) are typically 



15 provided by telephone companies (Telcos) or commercial Internet Service Providers 
(ISPs) who operate network access points along the information superhighway. It is 
through these network access points that the user is able to connect with public domains, 
such as the Internet, and private domains, such as an intra-company computer network of 
the user's employer. 



In wholesale Internet access environment, the network access provider (NAP) and 
the network service provider (NSP) are not necessarily the same entity. Telcos and other 
wholesale ISPs are typical NAPs, who operate gateways (network access servers, access 
routers, or the like) in their points of presence (PoPs), and provide local loop access 
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services to PCs. NSPs are typically the customers of NAPs, who are allowed to use the 
NAPs' gateways to provide their IP-based services, such as Internet access, network 
access, or voice over IP (VoIP) services to the PCs. 



currently available at NAPs. One is Point-to-Point Protocol (PPP) tunneling, typically 
using the Layer 2 Tunneling Protocol (L2TP) or Layer 2 Forwarding (L2F), and the other 
is IP-based forwarding such as Point-to-Point Protocol Terminated Aggregation (PTA), 
which terminates PPP sessions at the NAP and forwards IP frames. 



In the typical L2TP tunneling, a PC 1 of a PPP client starts a PPP session by 
dialing into a network access server (NAS) 2 located at the NAP's point of presence 
(PoP). The NAS 2 exchanges PPP messages with the client's PC 1 and communicates 
with a L2TP network server (LNS) 4 of an ISP or a private company. The LNS 4 is 
15 typically a home gateway (HGW) of the ISP or company's network. The communication 
between the NAS 2 and the LNS 4 is by way of L2TP requests and responses. When a 
L2TP tunnel 6 is set up, the NAS 2 forwards the PPP session over the L2TP tunnel 6 to 
the LNS 4. Data packets in the PPP session are encapsulated into L2TP frames that are 
destined for the IP address of the LNS 4. 



The LNS 4 is a termination point of the L2TP tunnel 6. The LNS 4 accepts these 
L2TP frames, strips the L2TP encapsulation, and processes the incoming PPP frames for 
the appropriate interface. The PPP frames are processed and passed to higher layer 
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protocols, i.e., the PPP session is terminated at the LNS 4. The PPP session termination 
requires and includes user authentication via a Remote Authentication Dial-In User 
Service (RADIUS) or other means. An authenticated PPP client then receives an IP 
address, a Domain Name System (DNS) address, and IP-based services that the client 
5 contracted. These are forwarded back to the client over the L2TP tunnel 6 through the 



The L2TP passes protocol-level (or Data Link-level) packets through the virtual 
tunnel between the endpoints of a point-to-point connection, i.e., the client's PC 1 and the 

10 LNS 4. The L2TP is suitable for virtual private networking (VPN), in which users can 
dial into a NAP's network access server and join a private (typically corporate) network 
that is remote from the NAS's PoP. Since the L2TP does not examine the destination IP 
address (the IP address in the private network), L2TP tunneling supports multiple IP 
address handling that is required for VPN. The L2TP is also suitable when the NAP does 

15 not bundle Internet access to its services or does not want to manage IP. 

However, as NAPs, especially Telcos, are facing increasing competitive pressure 
to lower pricing on their wholesale services, and ISPs are providing voice and video 
services over IP, Telcos are battling to enter IP-based service markets. The current PPP 
20 forwarding based on the tunneling technology, however, deprives the possibility for 
Telcos to offer IP-based services to their PPP clients, since the Telcos do not terminate 
PPP sessions and thus cannot touch IP frames. 



NAS 2. 



4 



EL575422448US £ ^^ketNo. CISCO-3041 

On the other hand, the other service architecture, typically the PPP Terminated 
Aggregation (PTA), allows Telcos to provide IP-based services to their PPP clients. In 
the typical PTA, a NAP terminates PPP sessions from PCs and then forwards IP traffic to 
its destination via a PVC/ATM connection, as shown in Fig. 1. Currently, it is possible 
5 for the NAP's single NAS 2 to provide both L2TP and PTA services, and let NSPs to 
choose the service they prefer. Thus, by coordinating with NSPs, Telcos are able to 
provide IP-based services to its PPP clients. However, once a NSP chooses the L2TP 
service from the NAP, the NAP has no means to provide IP-based services to PPP clients 
who are accessing the NSP. Since PPP clients are typically subscribers of the NSP's 
10 services and thus "owned" by the NSP, this is the most likely scenario. 



Furthermore, in a situation where a NAP offers both L2TP and PTA services, 
there still remains inconvenience for users to select the services in the PPP-based network 
access. In order to select another service from the NAS 2, such as connection to a HGW 
15 8 of a different network, the PPP client must terminate the existing PPP session and 

establish a new PPP connection to the NAS 2, since The L2TP connects a PPP client only 
to a single destination LNS 4. 
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BRIEF DESCRIPTION OF THE INVENTION 



A method provides computer network access to PPP clients. The method includes 
(a) receiving a PPP session creation request from a client, the PPP session creation 
request including a control protocol frame encapsulated therein, (b) obtaining user 
5 domain information associated with the PPP session creation request, (c) setting up a 
Layer 2 tunnel according to a parameter contained in the control protocol frame, (d) 
creating an ingress PPP object associated with an incoming PPP session, a host object 
associated with the client, and an egress PPP object associated with the Layer 2 tunnel, 
(e) creating an egress IP object based upon obtained user domain information, the egress 
10 IP object associated with IP-based forwarding, (f) linking the ingress PPP object, the host 
object, and the egress PPP object, thereby forwarding data packets from a PPP session 
with the client over the Layer 2 tunnel, and (g) linking the host object and the egress IP 
object, thereby forwarding IP frames received from the client over a link other than the 
Layer 2 tunnel. 



15 
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BRffiF DESCRIPTION OF THE DRAWINGS 
The accompanying drawings, which are incorporated into and constitute a part of 
this specification, illustrate one or more embodiments of the present invention and, 
together with the detailed description, serve to explain the principles and implementations 
5 of the invention. 



In the drawings: 

Fig. 1 is a diagram schematically illustrating two types of common service 
architectures for PPP clients currently available at NAPs. 

10 

Fig. 2 is a diagram schematically illustrating an architecture providing computer 
network access to PPP clients according to a presently preferred embodiment of the 
present invention. 



15 Fig. 3 is a diagram schematically illustrating an apparatus for providing computer 

network access according to a presently preferred embodiment of the present invention. 

Fig. 4 is a block diagram schematically illustrating an apparatus for providing 
computer network access according to a presently preferred embodiment of the present 
20 invention. 

Fig. 5 is a diagram schematically illustrating a typical data field format of a PPP 

frame. 
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Fig. 6 is a block diagram schematically illustrating an apparatus for providing 
computer network access according to a presently preferred embodiment of the present 
invention. 

5 

Fig. 7 is a diagram illustrating an example of a forwarding information base. 

Fig. 8 is process flow diagram illustrating a method for providing computer 
network access according to a presently preferred embodiment of the present invention. 

10 

Fig. 9 is process flow diagram illustrating a method for providing computer 
network access according to a presently preferred embodiment of the present invention. 

15 
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DETAILED DESCRIPTION 
Embodiments of the present invention are described herein in the context of a 
method and system for providing network access to PPP clients. Those of ordinary skill 
in the art will realize that the following detailed description of the present invention is 
5 illustrative only and is not intended to be in any way limiting. Other embodiments of the 
present invention will readily suggest themselves to such skilled persons having the 
benefit of this disclosure. Reference will now be made in detail to implementations of 
the present invention as illustrated in the accompanying drawings. The same reference 
indicators will be used throughout the drawings and the following detailed description to 
10 refer to the same or like parts. 

In the interest of clarity, not all of the routine features of the implementations 
described herein are shown and described. It will, of course, be appreciated that in the 
development of any such actual implementation, numerous implementation-specific 

15 decisions must be made in order to achieve the developer's specific goals, such as 
compliance with application- and business-related constraints, and that these specific 
goals will vary from one implementation to another and from one developer to another. 
Moreover, it will be appreciated that such a development effort might be complex and 
time-consuming, but would nevertheless be a routine undertaking of engineering for 

20 those of ordinary skill in the art having the benefit of this disclosure. 

In accordance with the present invention, the components, process steps, and/or 
data structures may be implemented using various types of operating systems, computing 
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platforms, computer programs, and/or general purpose machines. In addition, those of 
ordinary skill in the art will recognize that devices of a less general purpose nature, such 
as hardwired devices, field programmable gate arrays (FPGAs), application specific 
integrated circuits (ASICs), or the like, may also be used without departing from the 
scope and spirit of the inventive concepts disclosed herein. 



Fig. 2 schematically illustrates an exemplary PPP forwarding and IP forwarding 
architecture according to a presently preferred embodiment of the present invention. A 
PPP client (PC) 1 first starts a PPP session, for example, by dialing into a NAP's network 
10 access device 3. The network access device 3 is capable of forwarding a PPP session 
with the client 1 to a L2TP Network Server (LNS) 7 over a L2TP or L2F tunnel 5. The 
network access device 3 is also capable of forwarding IP frames received from the PPP 
client 1 over a link 10 other than the Layer 2 tunnel 5. 



15 The LNS 7 is typically a home gateway (HGW) of a network of a NSP, for 

example, an ISP or a private company. Receiving the PPP session, the LNS 7 terminates 
the PPP session, i.e., extracts the IP frame, examines the IP address, and provides IP- 
based services to the PC. In order to provide authentication for the clients, the LNS 7 
may include or be coupled with an Authentication, Authorization, and Accounting 

20 (AAA) server 9 using Remote Authentication Dial-In User Service (RADIUS), Terminal 
Access Concentrator Access Control Server PLUS (TACACS+), or the like. The LNS 7 
may also include or be coupled with a Dynamic Host Configuration Protocol (DHCP) 
server 11 that dynamically allocates an IP address to the client 1. Although the network 
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access device 3 may also be coupled with an AAA server 15 and a DHCP server 17, it is 
typically for the NSP to authenticate the PPP client 1 and to provide an IP address to the 
client 1 when the PPP session of the client 1 is forwarded over the L2TP tunnel 5. 



5 At the same time as forwarding the PPP session over the L2TP tunnel 5, the 

network access device 3 acts on the PPP session and enables the NAP to provide 
additional IP-based services to the PPP client 1. Such additional IP-based services may 
include access to another network, voice-over-IP (VoIP), video services over IP, and the 
like, via the link 10 other than the L2TP tunnel 5. The link 10 may be a permanent 

10 virtual circuit (PVC), asynchronous transfer mode (ATM) circuit, or the like, connecting 
to a router 13. The router 13 may be a HGW of a network, an edge router of a core 
network, a first router giving a hop to the backbone network, or the like. The IP frame 
forwarding is based on IP, or a protocol based on Layer 3 or higher. The PPP client 1 
does not have to terminate the current PPP session in order to obtain IP-based services 

15 via the link 10. Additionally, the network access device 3 may authenticate and/or 
provide an IP address to the same PPP client 1, if necessary, using the AAA server 15 
and/or the DHCP server 17. 

Fig. 3 schematically illustrates an apparatus 20 for providing network access 
20 according to a presently preferred embodiment of the present invention. The apparatus 
20 may be an access concentrator, an access router, or a similar network access device. 
For example, the present invention will be implemented in a Cisco 6400 Series Access 
Concentrator, available from Cisco Systems, Inc. of San Jose, California. 
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As shown in Fig. 3, the apparatus 20 includes a processor 21, a memory 31, a first 
interface 23 for receiving a PPP session (PPP session receiving interface 23), a second 
interface 25 for forwarding PPP session frames over a Layer 2 tunnel (Layer 2 tunneling 
5 interface 25), a third interface 27 for forwarding IP frames over a link other than the 
Layer 2 tunnel (IP frame forwarding interface 27). The apparatus 20 may also include 
one or more additional interface 29 to provide additional links. The processor 21 controls 
interfaces 23 -29 and the memory 31, and performs forwarding and routing operation for 
data packets, including decapsulation and encapsulation. 



Fig. 4 schematically illustrates the more detailed structure of the apparatus 20 
according to a presently preferred embodiment of the present invention. The memory 31 
contains an ingress PPP object 33 associated with the PPP session receiving interface 23, 
a host object 35 associated with the PPP client who is requesting network access, an 
15 egress PPP object 37 associated with the Layer 2 tunneling interface 25, and an egress IP 
object 39 associated with the IP frame forwarding interface 27. The memory 31 may also 
contain additional egress IP object 41 associated with the additional IP frame forwarding 
interface 29. In addition, the memory 31 may contain a forwarding information base 
(FIB) 36 associated with the host object 35. 



The processor 21 includes a user domain information determiner 43, an object 
generator 45, a PPP session forwarder 47, and an IP frame forwarder 49. They may be 
implemented as components of the software running on the processor 21. 
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Typically, in order to access a network through a network access device, a PPP 
client first makes a PPP session creation request, i.e., sends a data packet in a PPP frame. 
Fig. 5 illustrates an exemplary frame format of a PPP frame 50 as is well known to those 
5 of ordinary skill in the art. The PPP frame 50 includes Flag field 51, Address field 52, 
Control field 53, Protocol field 54, Payload field 55, and Checksum field 56. 

The Flag field 51 contains the standard High-level Data Link Control (HDLC) 
flag byte (011111 10). The Address field 52 is set to the binary value 1 1 1 1 1 1 1 1 to 

10 indicate that all stations are to accept the frame. Using this binary value avoids the issue 
of having to assign data link address. The Control field 53 has the default value of 
0000001 1, indicating an unnumbered frame. Since the Address field 52 and Control field 
53 are always constant in the default configuration, the Link Control Protocol (LCP) 
provides the necessary mechanism for two parties to negotiate an option to just omit them 

15 to save 2 bytes per frame. The Protocol field 54 indicates what kind of packet is in the 
Payload field 55. Codes are defined for the LCP, Network Control Protocol (NCP), IP, 
IPX, AppleTalk, and other protocols. Protocols starting with a "0" bit are network layer 
protocol such as IP, IPX, OSI CLMP, and XNS. Those starting with a "1" bit are used to 
negotiate other protocols. These include LCP and a different NCP for each network layer 

20 protocol supported. The default size of the Protocol field 54 is 2 bytes, but it can be 
negotiated down to 1 byte using LCP. The Payload field 55 has variable length, up to 
some negotiated maximum. If the length is not negotiated using LCP during the line set 
up, a default length of 1500 bytes is used. Padding may follow the payload, if necessary. 
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After the Payload field 55 comes the Checksum field 56, which is normally 2 bytes, but a 
4-byte checksum can be negotiated. 

The user domain information determiner 43 obtains user domain information 
5 associated with the PPP session creation request. The user domain information indicates 
how to proceed with the PPP session and where to connect the PPP client. The user 
domain information may be obtained from the PPP session creation request. For 
example, a PPP client typically uses a structured username in order to access the network, 
such as "usrname ©domain." The user domain information determiner 43 looks up a 
10 service profile that matches the "domain" string. The service profile may be stored 

locally in the apparatus 20, or a server such as a RADIUS server. The matching service 
profile may contain the IP address of the LNS and a password for the L2TP tunnel. 
Alternatively, the matching profile may contain the IP address of a HGW of an ISP to 
which services the client subscribes. 



In addition, the user domain information may be obtained from user identification 
information associated with a physical connection of the PPP session creation request, 
such as a line number (or telephone number) used by the client for transmitting the PPP 
session creation request. For example, if the NAP operating the apparatus 20 (or network 
20 access device 3 in Fig. 2) has contracted with Company A to provide private virtual 

networking between Company A and its branch, a specific phone number (or "caller ID") 
of the branch can be used to determine where to connect the client. In this case, a service 
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profile contains the line/phone number or VPI/VCI number and provides an IP address of 
the LNS of Company A. 



Furthermore, such user identification information or user specific information 
5 may be associated with a physical location of the client, client's PC, or the client 

premises equipment. For example, a specific line may be allocated to the premises of the 
branch of Company A. 



The object generator 45 creates in the memory 31 the various objects described 
10 above. The object generator 45 creates the egress PPP object 37 and the egress IP object 
39 based upon the user domain information obtained by the user domain information 
determiner 43. For example, if a user attempts to access a network from his/her 
workplace; a company's branch, the line ID information of the PPP session creation 
request may indicate a connection to a LNS of the private company, while the "domain" 
15 string of the username may indicate a HGW of an ISP, which is not a LNS. The object 
generator 45 creates the egress PPP object 37 for the connection to the company's LNS, 
and the egress IP object 39 for the connection to the ISP's HGW. The object generator 
45 may create the egress PPP object 37 as a default connection regardless of the 
determination of the user domain information determiner 43. 

20 

The PPP session forwarder 47 is responsible for Layer 2 forwarding. The PPP 
session forwarder 47 sets up a Layer 2 tunnel according to a parameter contained in the 
control protocol frame of the PPP session creation request. Such a setup may include 
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forwarding LCP negotiations with the PPP client to the LNS. After the object generator 
45 creates the objects, the PPP session forwarder links the ingress PPP object 33, the host 
object 35, and the egress PPP object 37, thereby forwarding data packets from the PPP 
session with the client via the Layer 2 tunneling interface 25. 



The PPP session forwarder 47 may include an IP address forwarder (not shown in 
Fig. 4). As described above, the LNS 7 (in Fig. 2) typically assigns an IP address to the 
authenticated PPP client and sends it to the network access device 3 through the Layer 2 
tunnel 5. The IP address forwarder receives the IP address and transfers it to the PPP 
10 client. 

The IP frame forwarder 49 is responsible for IP frame forwarding. It links the 
host object 35 and the egress IP object 39, thereby forwarding IP frames received from 
the client via the IP frame forwarding interface 27. The IP frames are forwarded through 
15 the IP frame forwarding interface 27 over a link other than the Layer 2 tunnel, for 
example, a PVC or ATM. 

Fig. 6 schematically illustrates an apparatus 30 for providing network access 
according to a presently preferred embodiment of the present invention. In Fig. 6, the 
20 like elements are indicated by the like reference numerals as those in Fig. 4. In the 

apparatus 30, the objects have more detailed structure and the egress PPP object 43 and 
the egress IP object 45 includes multiple objects. 
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An access PPP object (i.e., ingress PPP object) 33 is associated with a PPP 
connection with the client via the first interface 23. The egress PPP object 37 includes a 
connection object 61, an aggregation PPP object 63, and a tunnel object 65. The 
connection object 61 contains a range of IP addresses. The aggregation PPP object 63 is 
5 associated with outgoing PPP frames. The tunnel object 65 is associated with Layer 2 
tunneling through the second interface 25. Similarly, the egress IP object 39 includes a 
connection object 67 that contains a range of IP addresses, and a service object 69 
associated with IP frame forwarding through the third interface 27. 

10 The connection objects 61 and 67 are created according to the obtained user 

domain information. The connection object 61 may be created as the default connection. 
If the user domain information of the PPP client indicates yet another possible connection 
to a different network, the corresponding connection object 71 and the service object 73 
may be created during the setup stage, as shown in Fig. 6. 

15 

The PPP session is forwarded by making a link through the access PPP object 
33, the host object 35, the connection object 61, the aggregation PPP object 63, and the 
tunnel object 65, via the second interface 25 over the Layer 2 tunnel 81 to a LNS. When 
the PPP client wants to connect to a network through an IP-based link 83, the host object 
20 35, the connection object 67, and the service object 69 are linked. The IP frames from 
the PPP client are forwarded via the third interface 27. If the PPP client wants to connect 
to yet another network, the host object 35, the connection object 71, and the service 
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object 73 may be linked through and IP frames from the PPP client is forwarded via the 
fourth interface 29. 



Fig. 7 illustrates an example of the FIB 36. The FIB 36 contains associations 
5 between a network address and an interface descriptor block (IDB) indicating a 

connection to the corresponding interface. For example, such associations include one 
between the PPP client's IP address (public or assigned) and the ingress/access PPP 
object 33 that indicating connection to the PPP session receiving interface (the first 
interface) 23. For example, if the PPP client is an employee of Company A, such 
10 network address may be 10. 1 . 1 . 1 , or the PPP client is a user/subscriber of an ISP (ISP-B), 
such network address may be 134.1.1.1. 



The FIB 36 also includes an association between a default network address (i.e., 
0.0.0.0) and the egress PPP object 37 (or the connection object 61). This means that even 
15 if there is no matching destination DP address in the FIB 36, the FEB 36 still provides a 
link to the connection object 61 (or egress PPP object 37). Thus, the PPP session from 
the PPP client can be forwarded over the L2TP tunnel 81 without looking for the 
destination IP address. 

20 When the PPP client is an employee of Company A which has contracted PPP 

forwarding over the Layer 2 tunnel, the FEB 36 may also include an association between 
the Company's network address (for example, 10. x. x. x) and an IDB indicating the 
corresponding interface directing to the destination network (for example, the connection 
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object 61 associated with the Layer 2 tunneling interface 25). In addition, the FIB 36 
may include another association between a network address (for example, ISP-B's 
network: 134. x. x. x) and an IDB indicating the corresponding interface directing to the 
ISP's network (for example, the connection object 67 associated with the IP frame 
5 forwarding interface 27. The FIB 36 may further include yet another association between 
another network address (for example, 127. x. x. x) and an IDB indicating another IP 
frame forwarding interface 29, if the user domain information suggests such additional 
connection. Any number of connection objects may be created for one PPP client, i.e., 
for one host object. 



According to a presently preferred embodiment of the present invention, the FIB 
36 is stored in a form of a hash table. The key is the network address, and values are the 
various objects. By default, the FIB 36 contains entries for the ingress/access PPP object 
33 and connection object 61 (egress PPP object 37). 



Fig. 8 is a process flow diagram schematically illustrates a method of providing 
computer network access according to a presently preferred embodiment of the present 
invention. Fig. 6 is also referred to for explanatory purposes but by no means for intent 
of limitation. The following description, the method of the present invention may be 
20 performed by a network access device such as the apparatuses 20 as well as the apparatus 
30. Furthermore, the method of the present invention may be implemented in a product, 
device, or collection of devices and software products, and performed by a network 
access server, network access device, or aggregation device capable of such performance. 
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As shown in Fig. 8, a user (PPP client) initiates a PPP connection to a network 
access device, using an analog telephone system, integrated services digital network 
(ISDN), or the like. The network access device accepts the connection at the PoP, and 
5 the PPP link is established between the user and the network access device (101). The 
network access device receives a PPP session creation request from the user, and the user 
domain information, as described above, is obtained (102). Some information relevant to 
the user domain information (such as domain name and/or dial number ID) may be 
obtained during the partial authentication of the client for setting up the Layer 2 tunnel 
10 for the client. 

The regular L2TP tunnel setup process is performed according to a parameter 
contained in the control protocol frame of the PPP session creation request (103). For 
example, after the PPP link with the client is established, the network access device 

15 partially authenticates the PPP client using the Challenge Handshake Authentication 
Protocol (CHAP), the Password Authentication Protocol (PAP), or the like. The 
username, domain name, or Dial Number Identification Service (DNIS) is used to 
determine whether the user is a PPP client for Layer 2 tunneling (L2TP client), such as a 
Virtual Private Dialup Networking (VPDN) client. If the user is not a L2TP client, 

20 authentication may continue, and the client will access the Internet or other contracted 
services. If the user is a L2TP client, tunnel information such as a tunnel password, 
tunnel type, the LNS' IP address, and the like, is obtained from a service profile. Such a 
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service profile may be locally stored in the network access device or stored in a RADIUS 
server. 



The tunnel end points, the network access device and the LNS, may authenticate 
5 each other before any sessions are forwarded over a tunnel. Alternatively, the LNS can 
accept tunnel creation without any tunnel authentication of the network access device. 
Once the tunnel exists, a L2TP tunnel session is created for the client. 



The network access device may forward the LCP negotiations (LCP negotiated 
10 options) and the partially authenticated CHAP/PAP information to the LNS (105). The 
LNS will funnel the negotiated options and authentication information directly to the 
virtual access interface. If the options configured on the virtual interface does not match 
the negotiated options with the network access device, the connection will fail, and a 
disconnect message is sent to the network access device. 

15 

Then, the network access device creates an access PPP object 33 (111), a host 
object 35 (113), one or more connection objects 61, 67 and/or 71 (115), an aggregation 
PPP object 63 (119), a tunnel object 65 (121), and one or more service objects 69 and/or 
73 (123). As described above, these objects are created based on the information 
20 obtained through setup of the Layer 2 tunnel, including the partial authentication 
information and the user domain information. These various objects are created as 
object-oriented database structure during the setup or control stage of the Layer 2 
tunneling. 
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Creating connection objects may include maintaining a forwarding information 
base (FIB) 36 for the host object 35 (117). As discussed above, the FIB 36 contains 
associations between network addresses and interface descriptor blocks (or objects) 
corresponding to the links. 

Once the Layer 2 tunnel is setup and a necessary link is established, the LNS 
typically assigns an IP address to an authenticated client, and sends it to the network 
access device over the Layer 2 tunnel. The network access device receives the IP address 
and transfers it to the client (129). 

Then, in the forwarding stage, the network access device makes a process link 
through the access PPP object 33, the host object 35, the connection object 61, the 
aggregation PPP object 63, and the tunnel object 65 (125). Data packets from the PPP 
session (PPP frames) are forwarded through the Layer 2 tunneling interface 25 (127). An 
outgoing PPP frame is encapsulated in a L2TP frame and forwarded to the LNS over the 
Layer 2 tunnel 81. 

As shown in Fig. 9, in the PPP session, the network access device receives 
succeeding PPP frames from the client (131). Through decapsulation, the network access 
device examines the PPP frames (133) and determines destination IP address of the data 
packets (135). The FIB 36 is searched for a matching IP address (137). If there is no 
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matching address other than the default link, the data packets are remain forwarded 
through the same link over the Layer 2 tunnel (139). 

When the destination IP address matches to one network address on the FIB 36, 
5 the network access device select one of the connection object (141). Each connection 
object has a certain range of TP addresses and the network access device looks up the 
connection object to determine whether the destination IP address is within the IP address 
range of the connection object (143). For example, when the client attempts to access a 
different server within the same network that the client is currently connecting through 
10 the Layer 2 tunnel, the connection object 61 remains the same even though the 

destination IP address changes. The network access device forwards the data packet 
through the existing link over the Layer 2 tunnel (147). The data packet (PPP frame) is 
encapsulated into a L2TP frame and sent to the LNS. 



15 When the destination IP address is not within the range of the connection object 

61, but within the address range of the connection object 67, for example, the PPP client 
is attempting to access a different network through a link 83 other than the Layer 2 tunnel 
81. Thus, the network access device uses the corresponding link through the selected 
connection object 67. That is, the network access device forwards the data packets (IP 

20 frames) using the link though the host object 35, the connection object 67, the service 
object 69, and the IP frame forwarding interface 27 (149). The IP frames are forwarded 
to a router for IP-based forwarding/routing. It should be noted that the possible links for 
the PPP client have been established in the setup stage described above, and in the 
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forwarding stage, the network device uses one of the links in accordance with the 
selected connection object. 



Through this IP-based link 83 or another, the NAS is allowed to provide IP based 
5 to services to the PPP client. The link 83 or 85 may be coupled to any router, server, or 
other network device to provide such services. For example, NAS may provide web- 
based service selection to the client, voice or video over IP, and the like. 



As described above, the PPP client who has connected to a network via Layer 2 
10 tunneling can access another network though IP-based connection without terminating 
the existing PPP session. The NAP can also provide IP-based services to the PPP client 
through a link other than the Layer 2 tunnel without impairing the L2TP access services 
for the PPP client and the LNS. 

15 While embodiments and applications of this invention have been shown and 

described, it would be apparent to those skilled in the art having the benefit of this 
disclosure that many more modifications than mentioned above are possible without 
departing from the inventive concepts herein. The invention, therefore, is not to be 
restricted except in the spirit of the appended claims. 
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